Multimedia services have been developed to be provided for mobile terminals. The architecture of the present IP Multimedia Subsystem (IMS) providing multimedia services for mobile terminals is as shown in FIG. 1. Originally, the IMS is a sub-domain overlaid on the conventional Packet Switched (PS) domain of the 3rd Generation (3G) network, and the sub-domain is especially for use in supporting IP Multimedia (IM) services. When conditions are met, the IMS can also serve subscribers who access the network via a Wireless Local Area Network (WLAN) or other IP Connectivity Access Networks (IP-CAN).
As shown in FIG. 1, the IMS is primarily composed of a Call Session Control Function (CSCF), a Media Gateway (MGW), a Media Resource Function Controller (MRFC), a Media Resource Function Processor (MRFP), a Media Gateway Control Function (MGCF), a Breakout Gateway Control Function (BGCF), a Subscription Locator Function (SLF) and a Policy Decision Function (PDF), and the Session Initiation Protocol (SIP) is generally used for transmitting the control signaling between various components. A call control component is a key component of the IMS, which mainly implements functions such as call control, address translation, charging, and concealing the mobility of mobile User Equipment (UE); a media gateway component is introduced so as to be compatible with the conventional Public Switched Telephone Network (PSTN). In addition, the Home Subscriber Server (HSS) of the IMS is a device for use in storing the subscription information of an IMS subscriber.
The security function of the IMS includes the authentication of subscribers and the protection of SIP information in the IMS. The security architecture of the IMS is as shown in FIG. 2, where the bidirectional authentication mechanism of IMS Authentication and Key Agreement (AKA) is used for the authentication and Security Association (SA) negotiation between UE and the home network, and the hop by hop fashion is adopted for the encryption and the integrity protection of an SIP message.
Specifically, in the IMS, in order to authenticate an IP Multimedia (IM) subscriber, a dedicated IMS Subscriber Identity Module (ISIM) is used as the authentication module of the subscriber side in the 3rd Generation Partnership Project (3GPP) protocol, and the AKA mechanism of Universal Mobile Telecommunications System (UMTS) is used. The procedure of authenticating subscribers by the IMS system is as shown in FIG. 3, which includes the following steps.
Step 301: while using an IMS service, UE sends a register request to a Serving Call Session Control Function (S-CSCF) via a Proxy Call Session Control Function (P-CSCF) and an Interrogating Call Session Control Function (I-CSCF) in turn.
Step 302: upon receiving the register request, the S-CSCF detects whether a quintuplet Authentication Vector (AV) for the subscriber is saved by the S-CSCF; if yes, the S-CSCF authenticates the subscriber using the AV, i.e. proceeds to Step 304; otherwise, requests an AV from the HSS, i.e. proceeds to Step 303.
The quintuplet AV here includes a random number (RAND), an Authentication token (AUTN), a Cipher Key (CK) used by a Global System for Mobile communications (GSM) network, an Integrity key (IK) and an expected response (XRES).
Step 303: upon receiving the AV request sent from the S-CSCF, the HSS determines the quintuplet AV and sends the quintuplet AV to the S-CSCF.
The process of determining the quintuplet AV by the HSS includes: determining a Sequence Number (SQN) by the Authentication Centre (AUC) built in the HSS itself, and generating the quintuplet AV according to the SQN.
Obviously, in order to raise the efficiency, the HSS generally sends multiple groups of quintuplet AVs to the S-CSCF in sequence, so that the S-CSCF can obtain multiple groups of quintuplet AVs for authentication via one request.
Step 304: the S-CSCF reserves the XRES of the quintuplet AV sent from the HSS or of the quintuplet AV stored by the S-CSCF itself and inserts the RAND, AUTN, CK and IK into an authentication challenge (Auth_Challenge) message, and sends the Auth_Challenge message to the P-CSCF via the I-CSCF.
If the HSS sends multiple groups of quintuplet AVs to the S-CSCF, the S-CSCF may select one group of quintuplet AVs in sequence, and other groups of quintuplet AVs will be used in the next authentication for the subscriber.
Step 305: the P-CSCF reserves the CK and the IK sent from the S-CSCF via the Auth_Challenge message, and issues the RAND and the AUTN to the UE.
If the system starts the integrity protection and security protection, the P-CSCF will use the IK and CK reserved by itself as an encryption key in the subsequent sessions.
Steps 306-307: the UE sends the RAND and the AUTN received from the P-CSCF to the ISIM; the ISIM verifies the AUTN received from the UE and calculates a response (RES) according to the RAND after the verification has passed, and sends the RES calculated by the ISIM to the UE as an authentication response; the UE returns the RES to the S-CSCF while the ISIM further calculates an IK and an CK according to the RAND and sends the IK and the CK calculated according to the RAND to the UE.
The process of verifying the AUTN received from the UE includes: determining whether the Media Access Control (MAC) value contained in the AUTN received from the UE is legitimate and determining whether the Sequence Number (SQN) contained in the AUTN received from the UE is acceptable. At this point, the process of verifying whether the SQN is acceptable is the process of verifying whether resynchronization is needed.
Specifically, the UE sends the RES to the S-CSCF via the P-CSCF and the I-CSCF, and reserves the IK and the CK as encryption key for use in the subsequent sessions.
Steps 308-309: the S-CSCF compares the RES in the authentication response sent from the UE with the XRES stored by the S-CSCF itself; if they are identical, determines that the authentication has passed, and sends an authentication success message to the UE via the I-CSCF and P-CSCF; otherwise, determines that the authentication fails.
The authentication in the IM domain needs to be implemented by using an ISIM alone in the above procedure, that is to say, at present the configured ISIM is especially used for implementing the authentication in the IM domain while no terminal subscriber identity modules that can be used in 3G include an ISIM at present, which makes it impossible for such terminal subscriber identity modules to implement the authentication in the IM domain through the above procedures. For example, the conventional Universal Integrated Circuit Card (UICC) for 3G generally includes a Universal Subscriber Identity Module (USIM) used for authentication in the Circuit Switched (CS) domain and in the PS domain, which makes it impossible to implement the authentication in the IM domain through the above processing for the ISIM. Meanwhile, there are no data related to the USIM in the HSS, which makes it impossible to determine the required AV for authenticating a USIM subscriber, and as a result, impossible to authenticate the USIM directly through the above procedures.
In order to enable the HSS to complete the authentication of a USIM subscriber, one solution is to integrate the data of a Home Location Register (HLR) into the HSS such that the HSS could obtain the data related to the USIM so as to determine the AV. Obviously, it is necessary to replace the conventional HLRs on a large scale. Since the current IMS networks are still at the initial stage, it is impossible on the whole to replace HLRs on a large scale. A more rational solution is to overlay one or more special HSSes for providing IM services on the conventional networks while the conventional HLRs remain unchanged so as to provide the CS and PS domain services continually. According to the solution proposed by 3GPP, however, the HSS overlaid needs to use the ISIM to implement the authentication while the original HLR can use the original USIM to implement the authentication, thereby requiring the subscriber to replace the original card by a card containing an ISIM. In the current operating mode, if a subscriber wants to upgrade his UE, there are various solutions including purchasing a new UE or upgrading the old UE via a Java interface or other interfaces provided by UE manufacturers, which are all highly operable. If the subscriber wants to change the card, however, he has to change it at the special business spots authorized by operators; meanwhile, in order to guarantee the continuity of services, the International Mobile Subscriber Identity (IMSI) of the new card must be associated in some way with the IMSI of the old card, for example, they must share the same HLR, therefore, the actual operation to change a card is surely very boring.
Moreover, even though there are data related to the USIM stored in the HSS and the AV required for authentication of a USIM UE may be determined, other problems still exist, for example, it may cause a resynchronization if one USIM is used for authenticating multiple domains simultaneously. The so-called resynchronization means that the USIM will synchronize the SQNHE in an HSS/HLR with the SQNMS saved in the USIM itself, for example the USIM UE informs the HSS/HLR to replace the SQNHE with the SQNMS, in the case that the SQN in the quintuplet AV issued by the HSS/HLR is older than the SQNMS stored by the USIM while the issued SQN is in line with the SQNHE stored by the HSS/HLR and the SQN in the quintuplet AV indicates that the SQNHE is older than the SQNMS. Furthermore, if both HSS and the HLR store SQNs, the inconsistency problem of SQNs between the HSS and the HLR may occur, thus, it necessary to resynchronize the SQNs between the HSS and the HLR.
Take the resynchronization between the USIM and the HLR as an example. In order to raise the accessing efficiency of a network, the Visitor Location Register (VLR) corresponding to the CS domain and the Serving GPRS Support Node (SGSN) corresponding to the PS domain in an conventional network generally demand multiple groups of AVs during one accessing process, but use only one group of AVs to conduct the authentication processing each time while saving other AVs automatically. In this case, if operation frequencies in each domain are different, for example, the operation of the subscriber in the CS domain may be more frequent, the SGSN and the VLR obtain five groups of authentication tuple successively, for example, the SQN obtained by the SGSN is 1 to 5 and the SQN obtained by the VLR is 6 to 10, after one group of authentication tuple is used by the SGSN and the VLR respectively, SQN MS stored in the USIM may be 6, while the SQN in other four groups of authentication tuples buffered in the SGSN, namely 2 to 5, is older than the highest sequence (SQNMS) received by the USIM. At this point, the SQNMS stored in the USIM is consistent with the SQN issued by the VLR; therefore, the USIM may synchronize the SQNHE in the HLR by using the SQNMS in the USIM itself, thereby making all the AVs currently stored in the SGSN/VLR invalid. The SQNHE is the individual sequence number stored for each subscriber in the HLR/AUC. It can be seen from the above example, if the difference between the operation frequencies in different domains is large, frequent resynchronization will occur.
To sum up, if an IM service is desired at present, an ISIM must be contained in the terminal subscriber identity module of the subscriber or the conventional HLR must be replaced. Obviously, on the one hand, it is not realistic to replace the conventional HLR in a short period. On the other hand, including an ISIM in the terminal subscriber identity module would set a relatively high requirement on the terminal subscriber identity module, which often means that the subscriber has to replace the USIM card. Frequently changing a card, however, will surely make IM services much less attractive and increase the difficulty for operators to promote IM services.
The inventors of the present application, in the design of the present invention, discovered the above issues. Hence it is highly desirable to improve techniques of authenticating a terminal subscriber identity module in an IP Multimedia (IM) domain.